Data communication in a computer network involves the exchange of data between two or more entities interconnected by communication links. The entities are typically software programs executing on hardware computer platforms, such as nodes; in particular, communication software executing on the nodes correlate and manage data communication with other nodes. The nodes typically communicate by exchanging discrete packets or frames of data according to predefined protocols. In this context, a protocol consists of a set of rules defining how the nodes interact with each other. Collectively, these hardware and software components comprise a communications network and their interconnections are defined by an underlying architecture.
Modem communications network architectures are typically organized as a series of hardware and software levels or xe2x80x9clayersxe2x80x9d within each node that interact to format data for transfer over the network. Predetermined services are performed on the data as it passes through each layer and the layers communicate with each other by means of the predefined protocols. The lower layers of these architectures are typically implemented in hardware and firmware, whereas the higher layers are generally implemented in the form of software running on the nodes attached to the network. Examples of such communications architectures include the the Internet communications architecture and the Systems Network Architecture (SNA) developed by International Business Machines (IBM) Corporation.
SNA is a mainframe-oriented network architecture that includes services generally similar to those defined in the Internet communications architecture. An SNA network consists of nodes and links, wherein the nodes are network components containing protocol implementations and the links are transmission facilities that carry data between two nodes configured to operate a data link control procedure. Examples of such nodes include a host mainframe computer, a control unit and an input/output (I/O) device that provides a user interface to the network. In one embodiment of the SNA network, the control unit and I/O device may be combined within a node, such as a workstation and in another embodiment, the control unit may be independent of the workstation and include a router to enable routing of data through the network to destination nodes, such as workstations.
The host is typically connected to the control unit through a high-performance communication subsystem called a mainframe channel. The channel comprises a plurality of components including an intelligent processor (i.e., channel CPU) that manages the protocol over the communications link and controls transfer of data between host (main memory) storage and I/O devices directly attached to the control unit. To that end, a channel may use one or more channel paths as the actual links between a host and the control unit. Channel paths include physical transmission links between the channel and control unit; examples of channel paths include bus-and-tag and enterprise system connection (ESCON) channel paths. Moreover, each I/O device is represented by a subchannel. A subchannel is similar to a virtual circuit in that it provides information about the associated I/O device and its attachment to the channel.
To transfer data in connection with an I/O operation, the channel CPU executes channel command words (CCWs) once started by a start subchannel operation. The start subchannel command is issued by the host CPU to instruct the channel CPU as-to the-location of a channel program; this command also specifies the subchannel on which the channel program should execute. The channel program consists of a collection of CCWs; the CCWs are the actual I/O commands (read, write, status, etc) that cause information to flow between the host and an I/O device. The control unit interprets these CCWs and adapts them to fit the characteristics of different I/O devices. Upon issuing a start subchannel operation, the host CPU is released to pursue other processing while the channel organizes the data referenced by the channel program and synchronizes its transfer between the I/O device and main memory.
Communication between a channel and control unit is typically governed by various protocols; a protocol originally developed by IBM Corporation for improving the efficiency of data communication between a host computer and a control unit is the common link access to workstation (CLAW) protocol. In a CLAW environment, the control unit is logically coupled to a CLAW device, which is typically a software entity executing on a node, such as a workstation. Data communication takes place over a channel via the exchange of data packets between the workstation and host. The CLAW protocol achieves data communication efficiency, in part, by avoiding host CPU interrupts during I/O operations through the continuous execution of channel programs over a subchannel dedicated to write operations and another subchannel dedicated to read operations.
Logical links are defined in CCWs for these read and write operations to establish multiple logical connections within each subchannel directed to different applications executing on the host and workstation. In fact, main goal of the CLAW protocol is to enable efficient switching among applications specified by the logical links to facilitate data transfers to appropriate outbound interfaces (e.g., FDDI or Ethernet). Accordingly, the logical links are a way to multiplex within a subchannel.
The CLAW protocol generally defines (i) command codes associated with CCWs and (ii) the order in which those command codes are specified in a CCW chain. A logical link number (0-31) is embedded in the CCW command code, wherein number 0 is reserved for a control link and numbers 1-31 specify application-to-application (data) links. The control link path is part of a read/write subchannel pair dedicated to CLAW protocol communication. The host CPU builds a channel program comprising a chain of CCW data structures in main memory that contain instructions (e.g., read, read header, write, transfer-in-channel (TIC)). These instructions are then executed in accordance with the CLAW protocol.
The CLAW protocol also defines two primary sets of control flows over the control link: system validate/system validate response and connection request sequence. The system validate/system validate response control flows are manifested as message packets that propagate over the control link, passing information as data within a predetermined packet format. Before sending data, a system validate/response message flow occurs over the control link to verify the names of the workstation and host.
The workstation and host names are configuration parameters used to ensure that the host is communicating with the proper workstation. If the workstation (or host) name contained in the system validate message is incorrect, a control application provides a non-match return code in the system validate response message along with the expected name. Upon completion of the system validate/response exchange, the control link (0) has been brought up and the host is xe2x80x9cawarexe2x80x9d of the workstation to which it is connected. However, logical data links still need to be established for application-to-application data communication.
In order to establish a data link between two communicating applications, a connection request sequence is executed between the host and workstation. A control application resident on the host is typically responsible for initiating the connection request sequence to establish logical links (1-31) for data transfers between applications. A channel adapter within the control unit/workstation controls logical link assignments for applications executing on the workstation. The connection request sequence operates to establish the actual links used for host application-to-workstation application data transfers; once established, various types of data flow over these application-application links (e.g., a Transmission Control Protocol/Internet Protocol (TCP/IP) application has IP packets flowing over the link).
The connection request originates in the host over control link 0 and is sent to the channel adapter which selects an available link and alters the connection request to reference that link. The adapter then passes the connection request onto the targeted application of the workstation. The channel adapter sends the connection response back to the host over the control link. If the workstation does not agree with the name of its application specified in the request, it returns a disconnect command; otherwise, a connection confirm response is provided to the host and the link is ready for data transfer.
The host CPU then issues a start subchannel (SSCH) command to the channel CPU instructing that latter CPU to initiate an I/O operation to the targeted application. The channel CPU executes the SSCH command, which points to the beginning of a CCW chain of a channel program in main memory. In the case of a read (or write) channel program, the channel CPU gains control of the program, reads each CCW in sequence and executes it to initiate the flow of data, along with the CCW command code, over the physical channel wire and through the control unit between the host main memory and the targeted application.
For each received CCW command code, the control unit responds with either xe2x80x9cYesxe2x80x9d, xe2x80x9cInvalid Commandxe2x80x9d or xe2x80x9cBusyxe2x80x9d. A yes response is followed by execution of the CCW command. Either the channel or the control unit can terminate an I/O operation. Termination implies that the targeted application has received or provided all data associated with the I/O operation and no longer requires channel facilities. Control unit initiated I/O termination indicates that the I/O operation has completed and the control unit is ready to execute another operation.
The conventional CLAW protocol described above xe2x80x9cstaticallyxe2x80x9d configures the network system with respect to the functions performed by the control unit or host, or the parameters defining communication over the data links coupling the control unit and host. For example, the host and workstation names are statically configured parameters of the system validate/system validate response exchange, as are the maximum read and write CCW sizes that are sent during the exchange. There is currently no way to negotiate optional functions or parameters in a dynamic manner without having to manually reconfigure the network. Accordingly, there is a need for an out-of-band technique (i.e., outside of the logical application links) for the host to inform the control unit that new, different options are to be employed. Moreover, this out-of-band technique should be backward compatible to avoid disrupting normal operation of a control unit that is not configured to operate with the new options.
The invention comprises an option request protocol that allows dynamic negotiation of options between a host computer and a control unit of a computer network. The protocol is manifested as an exchange of novel control messages over a control link used to establish logical data links for communication between the host and control unit. The options negotiated by the control message exchange generally pertain to additional functions performed by the control unit or host, or additional parameters for communication over the data links coupling the control unit and host.
Specifically, the option request protocol defines a fixed-length control message having a unique format comprising a header and a body. A command field of the header contains command codes specifying the type of control message, such as an option request message or an option request response message. The body of the control message includes an option name field and an option-specific parameter field whose contents may vary depending upon the type of option requested.
According to an aspect of the invention, the control unit or the host may initiate negotiation of an option by issuing an option request message over the control link. For example, the host may function as an option requester by generating and sending an option request message to the control unit. Upon receipt of the request, the control unit functions as an option responder by returning an option request response; such a response may include a generic return code (such as xe2x80x9coption acceptedxe2x80x9d or xe2x80x9coption not supportedxe2x80x9d) or an option-specific return code (pertaining to the specifically-requested option). If the option responder is not configured to operate with the novel protocol, no response is returned. According to a time out aspect of the invention, if a response is not received within a predetermined time period, the option requestor may assume that the option responder does not xe2x80x9cunderstandxe2x80x9d the option request protocol and negotiation terminates.
An advantage of the inventive protocol is that it facilitates dynamic negotiation between a host and a control unit without prior configuration constraints. Although the control unit is generally programmed with option-specific information, that information may be dynamically selected by a host using the option request/response message exchange. In addition, the time-out feature of the invention specifies a backward compatible mechanism for reliable operation among host computers or control units that are not configured to operate in accordance with the option request protocol.